Because it is easy to extract strings from an application source code or binary, secrets should not be hard-coded. This is particularly true for
applications that are distributed or that are open-source.
In the past, it has led to the following vulnerabilities:
Secrets should be stored outside of the source code in a configuration file or a management service for secrets.
This rule detects keys having a name matching a list of words (secret, token, credential, auth, api[_.-]?key) being assigned a pseudorandom
hard-coded value. The pseudorandomness of the hard-coded value is based on its entropy and the probability to be human-readable. The randomness
sensibility can be adjusted if needed. Lower values will detect less random values, raising potentially more false positives.
Ask Yourself Whether
- The secret allows access to a sensitive component like a database, a file storage, an API, or a service.
- The secret is used in a production environment.
- Application re-distribution is required before updating the secret.
There would be a risk if you answered yes to any of those questions.
Recommended Secure Coding Practices
- Store the secret in a configuration file that is not pushed to the code repository.
- Use your cloud provider’s service for managing secrets.
- If a secret has been disclosed through the source code: revoke it and create a new one.
Sensitive Code Example
apiVersion: v1
kind: Pod
metadata:
name: nginx-app
spec:
containers:
- name: nginx
image: "nginx:1.21.6"
ports:
- containerPort: 80
env:
- name: API_TOKEN
value: "f7a9s8d7f6as98df7a6s9d8f7a6sd9f87as6df" # Sensitive
Compliant Solution
apiVersion: v1
kind: Pod
metadata:
name: nginx-app
spec:
containers:
- name: nginx
image: "nginx:1.21.6"
ports:
- containerPort: 80
env:
- name: API_TOKEN
valueFrom:
secretKeyRef:
name: my-secret
key: api-key
See
